Release 10.1A: OpenEdge Deployment:
Managing 4GL Applications

Possible drawbacks of r-code

R-code has several possible drawbacks:

Limited portability across user interfaces — The "Developer product requirements and r-code portability" section earlier in this chapter describes the limitations of r-code portability. Depending on the number of incompatible environments requiring a separate compilation, you might have to keep track of multiple r-code trees.
Loss of portability between 64-bit platforms and 32-bit platforms — Starting in OpenEdge Release 10.1A, you must run 32-bit r-code with the 32-bit product and you must run 64-bit r-code with the 64-bit product. You cannot run 64-bit r-code with the 32-bit product, nor can you run 32-bit r-code with the 64-bit product.

If you want to maintain portability between 32-bit and 64-bit platforms, you can run 10.1A 32-bit r-code with 10.0x 32-bit or 64-bit product. However, you will lose some of the performance benefits you gain when running 64-bit r-code with the 64-bit product (such as very large memory).

Loss of compile-time flexibility — Because you deliver your application in a precompiled format, you cannot make use of compile-time functionality. For example, you cannot pass arguments to include files to determine sort order, field lists, etc. Users therefore cannot specify their preferences before compilation.
More to manage at the development site — R-code’s limited portability often requires you to manage multiple code trees for a single version of a single application. As you modify or fix your application and create new versions, the number of code trees can become quite large.

R-code is also tightly coupled with the application database. This tight coupling requires you to keep a copy of all of your application databases that have different CRC values or different time stamps (depending on which type of r-code you have). After numerous upgrades and fixes, the number of databases can grow quite large.

Time-stamp-based r-code requires a copy of new database for upgrades — When you modify the schema of your application database, you invalidate the existing r-code because you change the database’s time stamps. To deploy an upgrade, therefore, you must provide users with a new database (with the correct time stamps) for each new version of the application. Users are then required to dump their old data and load it into the new database. This is a time consuming process for larger databases. For very large databases, the time required to perform a dump and load can be unacceptable. Progress Software recommends that you use CRC checked sums instead of time stamps for more flexibility.